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(54) Dispositif et proced6 de traitement de donn^es pour la generation d'alarmes au sein d'un 
reseau de communications 



(57) Un dispositif de traitement de donn^es (1 ) com- 
porte des moyens de traitement (4) capables de rece- 
voir d'equipements (3) d'un reseau de communications 
des donnees primalres definissant des 6v§nements 
dans au moins un fonnat primaire, et de d^llvrer d un 
dispositif de gestion du reseau (2) des donn6es secon- 
daires definissant des alarmes representatives des ev6- 
nements, dans un format secondaire. Les moyens de 
traitement (4) comprennent un interpr^teur (5) muni de 
regies de conversion, agencees sous fomrie de 
« scripts » associes aux differents fonnats primaires 
d'ev6nement, et agenc§ pour convertir ^ I'aide de ces 
regies des donnees primalres, regues dans Tun des for- 
mats primalres, en donn6es secondaires dans le format 
secondaire interpr^table par le dispositif de gestion (2). 
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Description 

[0001 ] L'jnvention concerne le domaine de I'dchange 
de donn^es entre equipements d'un r6seau de commu- 
nications, et plus particuli^rement celui de la gestion s 
d'evenements survenant au sein desdits equipements. 
[0002] Les reseaux de communications compoitent 
g6n6ralement un dispositif de gestion de r6seau (ou 
NMS pour « Network Management System ») cense 
pr6venlr i'op^rateur lorsqu'un 6v6nement survient dans 
un equipement. Plus pr§cis§ment, chaquefois que sur- 
vient un evenement au sein d'un 6quipement, ou dans 
un materiel supervise par cet equipement, ce demier 
d§livre une notification representative dudit ^v^nement. 
Cette notification, plus connue sous Texpression anglal- 
se « Trap » lorsque le protocole de gestion du reseau 
est le protocole SNMP (pour « Simple Network Mana- 
gement Protocol » RFC 2571-2580), est constitute de 
donndes primaires agencies selon des formats (ou pro- 
tocoles) primaires. A reception de ces donn§es primal- 
res !e gestionnaire NMS analyse leur contenu, puis s'il 
reconnatt le premier format il gtnere une aiarme definie 
par des donntes secondaires agencies selon un uni- 
que fomnat (ou protocole) secondaire pr§d6fini. 
[0003] Or, du fait de leur grande varidte, les Equipe- 
ments d'un reseau utilisent frequemment des formats 
primaires d'echange differents, difficiles, voire impossi- 
bles, & modifier. Par consequent, les gestlonnalres NMS 
ne peuvent reconnaTtre qu'une partie des notifications 
qu'iis regoivent. 

[0004] Pour tenter de rem^dler a cet inconvenient, il 
a ete propose d'equlper le gestionnaire NMS d'un mo- 
dule de traitement de donnees primaires reposant soit 
sur un outi! de correlation de formats, soit sur des codes 
de programmes, soit encore sur des ficliiers de configu- 
ration. La premiere solution, reposant sur un outil decor- 
reiatlon, met en oeuvre des traitements dont la lenteur 
est redhibitoire. La deuxieme solution, reposant sur des 
codes de programmes, necessite des d6veloppements 
tres couteux. Enfin, la troisleme solution n'est pas suffi- 
samment souple pour convenir aux situations dans les- 
quelles les fomriats primaires sont assez differents, ce 
qui est generalement le cas. De plus, ces solutions ne 
permettent generalement pas de synchroniser ou re- 
synchroniser I'etat d'alamie des equipements au niveau 
du gestionnaire NMS. Par consequent, aucune solution 
proposee n'est reellement satlsfaisante. 
[0005] L'jnvention a done pour but de remedier k tout 
ou partie des Inconvenients precites. 
[0006] Elle propose ^ cet effet un dispositif de traite- 
ment de donnees comportant des moyens de traitement 
capables de recevoir d'equipements d'un reseau de 
communications des donnees primaires (ou notifica- 
tion) definlssant des evenements dans au moins un for- 
mat primaire, et de deilvrer k un dispositif de gestion du 
reseau (ou gestionnaire NMS) des donnees secondai- 
res definlssant des alamnes representatives des evene- 
ments, dans un format secondaire. 



[0007] Ce dispositif se caracterise par ie fait que ses 
moyens de traitement comprennent un interpreteur (ou 
« scripting engine ») muni de regies de conversion, 
agencees sous forme de « scripts » associes aux diffe- 
rents formats primaires d'evenement, et agence de ma- 
niere k convertir k I'aide de ces regies des donnees pri- 
maires, regues dans I'un des formats primaires, en don- 
nees secondaires dans le fonnat secondaire Interpreta- 
ble par le dispositif de gestion. 
[0008] Preferentieilement, I'interpreteur est agence 
pour effectuer ses conversions dans un format secon- 
daire de fichier de configuration k I'aide d'un langage 
interprete. Plus preferentieilement encore, le fomnat se- 
condaire de fichier de configuration est un fonnat de ty- 
pe XML (pour « extensible Markup Language » - ver- 
sion 1.0 recommandee par le W3C), et/ou le langage 
interprete est JavaScript (tel que defini par ECMA-262 
ECMAScrlpt: A general purpose, cross-platfomi pro- 
gramming language). 

[0009] Egalement de preference, iorsque ies don- 
nees primaires sont respectivement assoclees k des 
identifiants d'evenements, comme par exemple des 
identifiants d'objets (ou OID pour « Object identifier »), 
I'interpreteur peut etre agence de manifere k stocker cer- 
taines au moins des regies de configuration en corres- 
pondance d'identiflants d'evenements connus. Dans ce 
cas, I'interpreteur peut etre egalement agence de ma- 
niere k stocker au moins une regie de conversion defi- 
nlssant un script pardefaut destine aux donnees primai- 
res qui sont associees k un identifiant d'evenement in- 
connu. 

[0010] Avantageusement, i'interpreteur peut §tre 
agence de maniere a deduire de certaines donnees pri- 
maires regues (ou notification) des parametres d'alarme 
lui permettant de deiivrer au dispositif de gestion une 
aiarme parametree. Dans ce cas, les alarmes peuvent 
etre parametrees par des valeurs « codees en dur » et/ 
ou extraites des donn6es primaires, et/ou des valeurs 
extraites d'un equipement. Dans cette demiere hypo- 
these, i'interpreteur doit etre agence pour extraire d'un 
equipement du reseau, dont I'etat d'alarme est Inconnu 
(de preference de sa base d'infomnations de gestion ou 
MIB (pour « Management information Base »)), des in- 
formations choisies representatives de son etat d'alar- 
me, puis simuler remission de donnees primaires (ou 
notification) representatives de ces informations d'etat, 
de maniere k generer une aiarme destinee k signaler 
au dispositif de gestion i'etat d'alarme de 1' equipement. 
[0011] Parailleurs, les donnees primaires sont prefe- 
rentieilement regues dans des formats primaires detype 
SNMP (protocole de gestion de reseau Internet). 
[0012] Uinvention porte egalement sur un dispositif 
de gestion de reseau (ou gestionnaire NMS) compre- 
nant un dispositif de traitement du type de celui presente 
ci-avant. 

[0013] L'invention porte en outre sur un precede de 
traitement de donnees, dans lequel, k reception de don- 
nees primaires (ou notification) transmises par des equi- 
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pements d'un r^seau de communications et d^finissant 
des 6v§nements dans au moins un fonmat primaire, on 
delivre k un dispositif de gestion du reseau (ou gestlon- 
naire NI\/IS) des donn^es secondaires d^finissant des 
alanmes representatives des 6v6nements, dans un for- 
mat secondaire. 

[0014] Ce proc§d6 se caract6rise par le fait que son 
6tape de generation consiste a convertir k I'aide de re- 
gies de conversion, agencies sous fomne de « scripts » 
associ^s aux dlff6rents fomnats primaires d'ev6nement. 
des donn6es primaires, regues dans I'un des formats 
primaires, en donnees secondaires dans ie fonnat se- 
condaire interpretabie par le dispositif de gestion. 
[0015] Le precede selon ('invention poun'a comporter 
de nombreuses caracterlstiques complementaires qui 
pourront §tre prises s6par6ment et/ou en comblnaison, 
et en particulier: 

- on peut proceder k la conversion dans un fonnat 
secondaire de fichier de configuration k I'aide d'un 
langage interprete. II est alors preferable que le for- 
•mat secondaire du fichier de configuration soit un 
format de type XML, et/ou que ie langage interprete 
soit JavaScript ; 

en presence de donnees primaires associees res- 
pectivement k des identifiants d'evenements, on 
peut assocler certaines au moins des regies de con- 
version k des Identifiants d'evenements connus. 
Dans ce cas, 11 est avantageux que I'une au moins 
des regies de conversion soit deflnle par un script 
par defaut destine k des donnees primaires asso- 
ciees k un identifiant d'evenement inconnu ; 
on peut deduire de certaines donnees primaires re- 
gues des parametres d'alarme, de maniere k deii- 
vrer au dispositif de gestion une alamrie parame- 
tree, par exemple par des vaieurs « codecs en dur » 
et/ou des vaieurs extraites des donnees primaires 
et/ou des vaieurs extraites d'un equipement ; 
on peut extraire d'un equipement du reseau, dont 
I'etat d'alarme est inconnu, des infonnations choi- 
sies representatives de son etat d'alarme, puis si- 
muler I'emission de donnees primaires representa- 
tives de ces infomiations d'etat, de maniere k ge- 
nerer une alamne destinee k signaler au dispositif 
de gestion retat d'alanne de requipement. Cette ex- 
traction s'effectue preterentieilement dans la base 
d'informations de gestion de requipement 
concerne ; 

- les donnees primaires sont preferentiellement re- 
gues dans des formats primaires de type SNMP. 

[0016] L'inventlon peut notamment etre mise en 
oeuvre dans toutes ies technologies reseaux devant 
etre g6rees, et notamment dans les r6seaux de trans- 
mission (par exempie de type WDM, SONET, SDH), de 
donn6es (par exemple de type Internet-IP ou ATM) ou 
de voix (par exemple de type classique, mobile ou 
NGN). 



[001 7] D'autres caracterlstiques et avantages de I'in- 
vention apparaTtront k I'examen de la description de- 
tainee ci-apres, et de I'unique figure annexee qui illustre 
de fagon schematique un exemple de realisation d'un 

5 dispositif selon l'inventlon implante dans un gestlonnai- 
re NMS d'un r6seau de communications. Cette figure 
est, pour I'essentiel, de caractere certain. En conse- 
quence, elle pourra non seulement servir k completer 
l'inventlon, mais aussi contribuer k sa definition, le cas 

10 echeant. 

[0018] Le dispositif de traitement 1 selon I'invention 
est destine k aiimenter en alarmes un gestionnaire NMS 
(pour « Network Management System ») 2 d'un reseau 
de communications, par exemple de type Intemet. Dans 
15 Texempte illustre sur I'unique figure, ce dispositif 1 est 
implante dans le gestionnaire NMS 2, mais 11 pourrait 
etre implante dans un boTtier externe, couple audit ges- 
tionnaire NMS. 

[0019] Le reseau de communications comporte une 

20 multiplicite d'equipements de reseau 3, comme par 
exemple des serveurs, des terminaux, des commuta- 
teurs ou des routeurs, pouvant echanger des donnees 
selon un protocoie de gestion de reseau avec le ges- 
tionnaire NMS 2. 

25 [0020] Dans ce qui suit, on considered titred'exemple 
non limitatif que le reseau de communications est de 
type Internet (IP) et que le protocoie de gestion du re- 
seau est le protocoie SNMP (pour « Simple Networi< 
Management Protocol » RFC 2571-2580). Bien enten- 

30 du, I'invention s'applique k d'autres types de reseau, 
comme par exemple aux reseaux de transmission de 
type WDM, SONET ou SDH, de donnees de type ATM, 
ou de voix de type classique, mobile ou NGN, et k 
d'autres protocoles de gestion de reseau, comme par 

35 exempie TL1 ou CORBA. Les equipements 3 du reseau 
sont agences pour deiivrer au gestionnaire NMS 2 des 
notifications (ou messages), ici de type « Trap », defi- 
nies par des donnees primaires agencees selon un for- 
mat (ou protocoie) primaire, ici de type SNMP, chaque 

40 fois que survient un evenement en leur sein, ou dans 
un equipement ou materiel qu'ils controient. Les don- 
nees primaires d'une notification definissent par conse- 
quent un evenement survenu dans un equipement 3. 
Une multiplicite de fomnats primaires differents peut 

45 coexister au sein du reseau. Par ailteurs, chaque notifi- 
cation est preferentiellement associee k un identifiant 
representatif d'un type d'evenement. 
[0021 ] Le dispositif de traitement 1 comprend un mo- 
dule de traitement 4 comportant un Interpreteur (ou 

50 « scripting engine ») 5 disposant d'une multiplicite de re- 
gies de conversion agencees sous la fomie de 
« scripts ^ associes dune multiplicite de fomiats primai- 
res d'evenement differents. 

[0022] Plus precisement, k chaque format primaire 
55 correspond un script particulier (ou regle(s) de conver- 
sion), preferentiellement stocke dans une memoire 6 en 
correspondance de I'un des Identifiants d'evenements 
contenus dans les notifications (ou Traps). II est egale- 
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ment pr^f^rable de pr^voir au moins un script par d^faut 
pour trailer (ou inltier le traitement) les donn6es primai- 
res agencies selon un format primaire qui est associ^ 
& un identifiant d'6venement Inconnu. 
[0023] Ainsi, iorsqu'un Interpr^teur 5 re90it una noti- 5 
fication (ou Trap), II en extrait ridentifiant d'evenement 
et determine ia r^gie de configuration (ou script) stocl^^e 
qui iui correspond. II peut alors appliquer ce script (ou 
regie) aux donnees primaires definissant la notification, 
de manl^re ^ gdn^rer une alarme d^finie par des don- 
nees secondaires agencies dans un langage interprdtd 
et selon un unique fomnat secondaire interpr^table par 
un module de contrdle 7 du gestionnaire NMS 2. En 
d'autres termes, les donnees primaires regues, agen- 
cees selon un format primaire et representatives d'un 
6v6nement, sont « converties » en donn6es secondai- 
res agencies selon un format secondaire et dans un 
langage Interprets. 

[0024] A reception d'une telle alanne, le module de 
controle 7 du gestionnaire NMS 2 peut alors provoquer 
rafficiiage de ralanne sur un 6cran de controle dudit 
gestionnaire NMS et/ou decider d'action(s) k entrepren- 
dre dans le rSseau pour tenir compte de Tatanne et/ou 
rem6dier k sa cause. 

[0025] L'interpreteur 5 est agence, k reception de 
donnees primaires, pour generer, k I'alde du script qui 
correspond aux donnees primaires re9ues, une alarme 
definie par des donnees secondaires. Dans un mode de 
realisation preferentiel, ces donnees secondaires sont 
agencees sous la fonne d'un fichier de configuration 
d'alarme selon un fonnat (ou protocole) secondaire. de 
preference de type XML (pour « extensible Markup 
Language »), et dans un langage interprete (ou 
« scripting language »), de preference de type JavaS- 
cript (tel que defini par ECMA-262 ECMAScript : A ge- 
neral purpose, cross-ptatform programming language). 
Plus preferentiellement encore, on choisit la version 1 .0, 
du format XML recommandee par W3C. 
[0026] Bien entendu, d'autres langages interpretes 
(ou « scripting languages ») et d'autres fomnats secon- 
daires pourraient etre envisages. Ainsi, XML peut §tre 
remplace par des formats textes proprietaires. De me- 
me, le langage JavaScript des scripts peut etre rempla- 
ce, par exemple, par Visual Basic, TCL, Perl ou encore 
Python. 

[0027] Dans cet exemple, I'identlfiant d'evenement, 
permettant k l'interpreteur 5 de determiner le script cor- 
respondant au fonnat primaire des donnees primaires 
revues, est preferentiellement de type OID (« Object 
Identifier »- identifiant de type simple ASN.1 pennettant 
d'identifier un objet tel qu'un 6venement), dans la me- 
sure oCi le langage interprete, utilise par l'interpreteur 5 
pour generer ies fichlers de configuration (donnees se- 
condaires), est JavaScript. 

[0028] La syntaxe utilisee pour generer les f ichiers de 
configuration d'alarme (ou donnees secondaires) est 
done Ici une comblnaison de XML et de JavaScript. Plus 
preclsement, d'une premiere part, la structure generale 



du fichier est de type XML, d'une deuxieme part, les 
donnees secondaires, definissant Talanne associee k 
une notification OID regue, sont toujours encadrees par 
deux blocs (ou « tags ») XML, d'une troisieme part, cha- 
que champ de I'alarme possdde une unique entree, et 
d'une quatrieme part, chaque entree de I'alarme estsoit 
une constante, soit une expression JavaScript. 
[0029] Ainsi, lorsque toutes les entrees de i'alamrie 
sont des constantes, le fichier de configuration d'aianme 
est principalement de type XML. Par exemple, it se pre- 
sente sous la fonne <SEVERlTY>Critical</SEVERI- 
TY>. Lorsque certaines au moins des entrees de I'alar- 
me sont des expressions JavaScript, un maximum de 
souplesse peut §tre obtenu. Le fichier se presente alors, 
par exemple, sous la fonne <SEVERiTY> (trapget(«< 
1 .2.3.4 >»)==2) ? Critical : Major</SEVERITY>. 
[0030] Certains champs de I'alamne generee peuvent 
etre optionnels ou presenter une valeur par defaut. 
[0031] Grace aux scripts, II est possible de tirer plei- 
nement partie des informations contenues dans les don- 
nees primaires qui constituent les notifications regues. 
De nombreux traitements, notamment logiques et/ou 
calculatoires, peuvent §tre ainsi appliques aux parame- 
tres qui definissent les evSnements signaies par les 
equipements 3 du reseau. Par consequent, l'interpre- 
teur 5 peut non seulement generer une alamie repre- 
sentative d'un evenement, mais egaiement accompa- 
gner cette alarme de parametres (ou de valeurs de pa- 
rametres) susceptlbles d'en faciliter le traitement au ni- 
veau du gestionnaire NMS 2. 
[0032] Les alannes peuvent ainsi §tre parametrees 
par des valeurs <« codees en dur » et/ou extraites de la 
notification (ou Trap) et/ou extraites d'un equipement 
dont on a regu une notification (ou Trap). 
[0033] Af in de mettre en oeuvre cette troisieme pos- 
sibilite, l'interpreteur 5 doit etre agence de maniere k 
adresser k un equipement, dont II a eventuellement re^u 
des donnees primaires representatives d'un etat d'alar- 
me inconnu, un message requerant de sa part certaines 
Informations susceptlbles de permettre la determination 
dudit etat d'alamne. Generalement, ces informations 
sont contenues dans la base d'informatlons de gestion 
8 (ou MIB pour « Management Information Base ») de 
requlpement 3. 

[0034] Grdce k cet agencement Iui permettant d'ex- 
traire des informations d'un equipement 3 distant, et no- 
tamment de sa MIB 8, le dispositif selon I'invention 1 
peut assurer une fonction de synchronisation et resyn- 
chronisation de I'etat d'alamne de chaque equipement. 
En effet, chaque fois que le gestionnaire NMS du reseau 
2 (ou son dispositif de traitement 1) est redemarre ou 
deconnecte du reste du reseau, par exemple en cas de 
panne ou d'intervention de maintenance, 11 doit etre, 
d'une part, resynchronise par rapport aux etats d'alar- 
mes respectifs des equipements 3 du r6seau qui etaient 
presents au moment de sa deconnexion, lesquels etats 
ont pu evoluer, et d'autre part, synchronise par rapport 
aux etats d'atarmes respectifs des nouveaux equipe- 
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ments 3 du r^seau, lesquels 6tats lui sont inconnus. tl 
en va de meme cheque fois qu'un nouvel dquipement 3 
se connecte au reseau ou qu'un ancien 6quipement se 
reconnecte au r6seau. 

[0035] Cette fonction peut §tre assur^e par une ou 
plusieurs regies, par exemple stockees dans la m6nnoi- 
re 6, soit automatiquement tors de chaque mise en fonc- 
tionnement et/ou chaque fois que I'interpreteur 5 est 
averti d'une (re)connexion par le module de controle 7 
du gestionnaire NMS 2 du reseau, soit semi-automati- 
quement chaque fois que la personne responsable de 
la gestion du r6seau en donne I'ordre ^ I'interpreteur 5. 
[0036] La ou les regies de (re)synchronisation sont 
agencies pour examiner lecontenu delaMIBdu ou des 
^quipements 3 d^sign^s, de manldre k extraire les in- 
formations (param6tre(s) ou valeur(s) de parametre(s)) 
definissant ieur(s) 4tat(s) d'alamne. Mais, ces rdgles 
peuvent 6galement servir k verifier ou contrdler la valeur 
d'un ou plusieurs param6tres. Comme indiqu6 ci-des- 
sus, dans certaines situations tous les 6quipements du 
reseau, qui dialoguent avec le gestionnaire NMS 2, peu- 
vent faire I'objet d'un examen k I'aide des regies de (re) 
synchronisation. 

[0037] La ou les regies de {re)synchronlsation peu- 
vent etre agencies de manidre k simuter remission 
d'une notification (ou Trap) a I'lnterieur du gestionnaire 
NMS 2. Plus precis^ment, elles indiquent les notifica- 
tions (ou Traps) que I'^quipement 3 aurait dO envoyer 
pour passer d'un etat sans alarme k son 6tat en cours. 
Ces notifications (ou Traps) simutees font ensuite I'objet 
d'une conversion semblable a celle appliquee aux noti- 
fications r^elles. 

[0038] Le module de traitement 4 du dispositif 1, et 
son interpreteurS, peuvent etre respectivement realises 
sous la forme de circuits electroniques, de modules lo- 
glciels (ou informatiques), ou d'une comblnalson de cir- 
cuits et de logiciels. 

[0039] L'invention offre egalement un proced6 de trai- 
tement de donn§es, dans lequel, k reception de don- 
nees primaires transmises par des equipements 3 d'un 
r6seau de communications et d6finissant des 6v6ne- 
ments dans au moins un format primaire, on d6livre k 
un dispositif de gestion du reseau 2 (ou gestionnaire 
NMS) des donnSes secondaires qui d^finissent des 
alarmes representatives de ces ev^nements, dans un 
format secondaire. 

[0040] Celui-ci peut §tre mis en oeuvre a I'aide du dis- 
positif de traitement presents ci-avant. La fonction prin- 
clpale et les sous-fonctions optionnelies assur^es par 
les etapes de ce proc6d6 6tant senslblement identiques 
k celles assur6es par les diff6rents moyens constituant 
le dispositif de traitement 1 , seule sera r^sum^e ci- 
aprds Tetape mettant en oeuvre la fonction principale du 
precede selon l'invention. 

[0041] Ce precede se caract6rise par le fait que son 
etape de generation consiste k convertir k I'aide de re- 
gies de conversion, agencees sous fomne de « scripts » 
associes aux differents f omiats primaires d'evenement, 
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des donnees primaires, re9ues dans Tun des formats 
primaires, en donnees secondaires dans le format se- 
condaire interpretabie par le dispositif de gestion 2. 
[0042] GrSce k l'invention, il n'est plus necessaire de 
5 recourir k la programmation. ce qui penmet de reduire 
les coOts de developpement. De plus, les scripts procu- 
rent une grande souplesse d'utilisation et une grande 
rapidite de traitement (plusieurs dizaines de notifica- 
tions (ou Traps) par seconde), et permettent une adap- 

10 tatlon raplde k tous les types de fomnats primaires. En 
outre, rinventlon permet une (re)synchronisation. 
[0043] L'invention ne se limite pas aux modes de rea- 
lisation de precede et dispositifs decrits ci-avant, seule- 
ment k titre d'exemple, mais elle englobe toutes les va- 

15 riantes que pourra envisager I'homme de Tart dans le 
cadre des revendicatlons ci-apres. 



Revendications 

20 

1 . Dispositif de traitement de donnees (1 ) comportant 
des moyens de traitement (4) propres k recevoir 
d'equlpements (3) d'un reseau de communications 
des donnees primaires definissant des ev6nements 

25 dans au moins un format primaire, et k deiivrer ^ un 
dispositif de gestion dudit reseau (2) des donnees 
secondaires definissant des alamnes representati- 
ves desdits evenements, dans un format secondai- 
re, caracterise en ce que lesdits moyens de tral- 

30 tement (4) comprennent un Interpreteur (5) muni de 
regies de conversion, agencees sous fonme de 
« scripts » associes aux differents formats primal- 
res d'evenement, et agence pour convertir k I'aide 
desdites regies des donnees primaires, re9ues 

35 dans I'un desdits formats primaires, en donnees se- 
condaires dans ledit format secondaire interpreta- 
bie par ledit dispositif de gestion (2). 

2. Dispositif selon la revendication 1 , caracterise en 
40 ce que ledit interpreteur (5) est agence pour effec- 

tuer lesdites conversions dans un format secondai- 
re de fichier de configuration k I'aide d'un langage 
interprete. 

45 3. Dispositif selon la revendication 2, caracterise en 
ce que ledit fomnat secondaire de fichier de confi- 
guration est un fomnat choisi dans un groupe com- 
prenant XML et les formats textes proprietalres. 

50 4. Dispositif selon I'une des revendications 2 et 3, ca- 
racterise en ce que ledit langage interprete est 
choisi dans un groupe comprenantau moins JavaS- 
cript, VisualBasIc, TCL, Perl et Python. 

55 5. Dispositif selon I'une des revendications 1 k 4, ca- 
racterise en ce que, en presence de donnees pri- 
maires associees respectivement k des Identif iants 
d'evenements, ledit interpreteur (5) est agence pour 
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stocker certaines au moins desdites regies en cor- 
respondance d'Identifiants d'6v6nements connus. 

6. Dispositif seion la revendication 5. caracterise en 
ceque teditinterpr^teur (5) est agenc6 pour stocker 
au moins une rdgle de conversion d^finissant un 
script par defaut destine aux donnees primaires as- 
socl^es k un Identiflant d'§v§nement Inconnu. 

7. Dispositif seion I'une des revendications 1 k 6, ca- 
racterise en ce que ledit interpreteur (5) est agen- 
cy pour d6duire de certaines donn6es primaires re- 
5ues des parametres d'alarme, de manifere k d6li- 
vrer audit dispositif de gestion (2) une alarme para- 
m6tr6e. 

8. Dispositif seion la revendication 7, caracterise en 
ce que ledit interpreteur (5) est agencS pour d^li- 
vrer au dit dispositif de gestion (2) des alarmes pa- 
rametr^es par des valeurs <« cod6es en dur », 

9. Dispositif seion I'une des revendications 7 et 8, ca- 
racterise en ce que ledit interpreteur (5) est agen- 
cy pour deiivrer audit dispositif de gestion (2) des 
alamnes param6tr6es par des valeurs extraites des- 
dites donnees primaires. 

10. Dispositif seion I'une des revendications 1 k 9, ca- 
racterise en ce que, lorsque Tetat d'alarme d'un 
equipement (3) du reseau est inconnu, ledit inter- 
preteur (5) est agence pour extraire dudit equipe- 
ment (3) des infomnations cholsles representatives 
dudit etat d'alamie, puis simuler remission de don- 
nees primaires representatives desdites informa- 
tions d'etat, de maniere k generer une alarme des- 
tinee k signaler au dispositif de gestion (2) I'etat 
d'alamrie dudit equipement (3). 

1 1 . Dispositif seion la revendication 1 0 en combinalson 
avec I'une des revendications 7^9, caracterise en 
ce que ledit interpreteur (5) est agence pour deii- 
vrer audit dispositif de gestion (2) des alarmes pa- 
rametrees par des valeurs extraites de Tequipe- 
ment duquel tl a regu des donnees primaires. 

12. Dispositif seion I'une des revendications 10 et 11, 
caracterise en ce que ledit interpreteur (5) est 
agence pour extraire lesdites informations ou va- 
leurs d'une base d'infomriations de gestion (8) de 
requipement concerne. 

13. Dispositif seion I'une des revendications 1 k 12, ca- 
racterise en ce que lesdites donnees primaires 
sent regues dans des fonnats primaires de type 
SNMP. 

14. Dispositif de gestion de reseau (2), caracterise en 
ce qu*il comprend un dispositif de traltement (1 ) se- 



ion I'une des revendications precedentes. 

15. Precede de traitement de donnees, dans iequel, k 
reception de donnees primaires transmises par des 

5 equlpements (3) d'un reseau de communications et 
definissant des evenements dans au moins un for- 
mat primaire, on deiivre k un dispositif de gestion 
du reseau (2) des donnees secondaires definissant 
des alarmes representatives desdits evenements, 

10 dans un fonnat secondaire, caracterise en ce que 
ladite generation consiste k convertir k I'aide de re- 
gies de conversion, agencees sous forme de 
« scripts » associes aux differents formats primal- 
res d'evenement, des donnees primaires, regues 

IS dans I'un desdits fomiats primaires, en donnees se- 
condaires dans ledit format secondaire interpr6ta- 
ble par ledit dispositif de gestion (2). 

16. Precede seion la revendication 15, caracterise en 
20 ce que Ton procdde k la conversion dans un format 

secondaire de fichier de configuration k I'aide d'un 
langage interprete. 

17. Dispositif seion la revendication 1 6, caracterise en 
25 ce que ledit fonnat secondaire de fictiier de confi- 
guration est un fonnat choisi dans un groupe com- 
prenant Xf^L et les formats textes prophetaires. 

18. Dispositif seion I'une des revendications 16 et 17, 
30 caracterise en ce que ledit langage interprete est 

choisi dans un groupe comprenant au moins JavaS- 
cript, VIsualBasic, TCL, Perl et Pytiion. 

19. Precede seion I'une des revendications 15^18,ca- 
35 racterise en ce que, en presence de donnees pri- 
maires associees respectivement k des identlfiants 
d'evenements, on associe certaines au moins des- 
dites regies de conversion a des identifiants d'eve- 
nements connus. 

40 

20. Procede selon la revendication 19, caracterise en 

ce que I'une au moins desdites regies de conver- 
sion definit un script par defaut destine k des don- 
nees primaires associees k un identlfiant d'evene- 
45 ment inconnu. 

21 . Precede selon I'une des revendications 1 5 & 20, ca- 
racterise en ce que t'on deduit de certaines don- 
nees primaires regues des parametres d'alamne, de 

50 maniere k deiivrer audit dispositif de gestion (2) une 
alarme parametr6e. 

22. Procede selon la revendication 21 , caracterise en 
ce que Ton deilvre audit dispositif de gestion (2) des 

55 alarmes parametrees par des valeurs « codees en 
dur», 

23. Procede selon I'une des revendications 21 et 22, 
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caracterlse en ce que Ton d^livre audit dispositif 
de gestion (2) des alarmes param^tr^es par des va- 
teurs extraites desdites donn^es primaires. 

24. Proc^d4selonrunedesrevendications15&23,ca- s 
racterise en ce que, lorsque T^tat d'atanne d'un 
6quipement (3) du r^seau est inconnu, on extralt 
dudit 6quipement (3) des informations cholsies re- 
presentatives dudit 6tat d'alamne, puis on simule 
i'6mlssion de donn6es primaires representatives io 
desdites informations d'6tat, de mani^re k g6n6rer 
une alanne destinee k signaler au dispositif de ges- 
tion (2) retat d'alarme dudit ^quipement (3). 

25. Proc6d§ selon la revendication 24 en combinalson is 
avec Tune des revendications 21 k 23, caracterlse 

en ce que I'on delivre audit dispositif de gestion (2) 
des alamnes param6tr6es par des valeurs extraites 
de r^quipement (3) duquel II a re9u des donn^es 
primaires. 20 

26. Precede selon I'une des revendications 24 et 25, 
caracterlse en ce que Ton extralt lesdites Informa- 
tions ou valeurs d'une base d'informations de ges- 
tion (8) de r^qulpement (3) concern^. 25 

27. Precede selon i'une des revendications 1 5 ^ 26, ca- 
racterlse en ce que lesdites donn^es primaires 
sont regues dans des fonnats primaires de type 
SNMP. 30 



28. Utilisation des precede, dispositif de traitement (1) 
et dispositif de gestion (2) selon I'une des revendi- 
cations prec§dentes dans les technologies r6seaux 
devant etre gerees. 35 

29. Utilisation selon la revendication 28, caracterlse 
en ce que lesdites technologies r^seaux sont choi- 
sies dans un groupe comprenant les r^seaux de 
transmission, en particulier de type WDM, SONET 
et SDH, de donn6es, en particulier de type Inter- 
net-IP et ATM, et de voix, en particulier de type clas- 
sique, mobile et NGN. 



50 



55 
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